
\section{Maintaining Your System}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Throughout this book, we will mainly deal with installation and
configuration issues. Administration is, however, much more than
that~--- after setting up a service, you have to keep it running, too.
For most of them, only little attendance will be necessary, while some,
like mail and news, require that you perform routine tasks to keep your
system up-to-date.  We will discuss these tasks in later chapters.


The absolute minimum in maintenance is to check system and
per-application log files regularly for error conditions and unusual
events. Commonly, you will want to do this by writing a couple of
administrative shell scripts and run them from \prog{cron} periodically.
The source distribution of some major appliations, like \prog{smail} or
C~news, contain such scripts. You only have to tailor them to suit your
needs and preferences.  A couple of sample scripts is reproduced in
appendix~\ref{appendix.scripts}.


The output from any of your \prog{cron} jobs should be mailed to an
administrative account. By default, many applications will send error
reports, usage statistics, or logfile summaries to the \user{root}
account. This only makes sense if you log in as \user{root} frequently;
a much better idea is to forward \user{root}'s mail to your personal
account setting up a mail alias as described in chapter~\ref{smail}).


However carefully you have configured your site, Murphy's law
guarantees that some problem \emph{will} surface eventually. Therefore,
maintaining a system also means being available for complaints. Usually,
people expect that the system administrator can at least be reached via
email as \email{root}, but there are also other addresses that are
commonly used to reach the person responsible for a specific aspect of
maintenence. For instance, complaints about a malfunctioning mail
configuration will usually be addressed \email{postmaster}; and problems
with the news system may be reported to \email{newsmaster} or
\email{usenet}. Mail to \email{hostmaster} should be redirected to the
person in charge of the host's basic network services, and the DNS name
service if you run a name server.


\subsection{System Security}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Another very important aspect of system administration in a network
environment is protecting your system and users from intruders.
Carelessly managed systems offer malicious people many targets:  attacks
range from password guessing to Ethernet snooping, and the damage caused
may range from faked mail messages to data loss or violation of your
users' privacy. We will mention some particular problems when discussing
the context they may occur in, and some common defenses against them.


This section will discuss a few examples and basic techniques in dealing
with system security.  Of course, the topics covered can not treat all
security issues you may be faced with exhaustively; they merely serve to
illustrate the problems that may arise.  Therefore, reading a good book
on security is an absolute must, especially in a networked system.
Simon Garfinkel's ``Practical UNIX Security'' (see \cite{security}) is
highly recommendable.


The sine qua non of system security is good system administration. This
includes checking the ownership and permissions of all vital files and
directories, monitoring use of privileged accounts, etc. The COPS
program, for instance, will check your file system and common
configuration files for unusual permissions or other anomalies. It is
also wise to use a password suite that enforces certain rules on the
users' passwords that make them hard to guess. The shadow password
suite, for instance, requires a password to have at least five letters,
and contain both upper and lower case numbers and digits.


When making a service accessible to the network, make sure to give it
``least privilege,'' meaning that you don't permit it to do things that
aren't required for it to work as designed. For example, you should make
programs setuid to \user{root} or some other privileged account only
when they really need this. Also, if you want to use a service for only
a very limited application, don't hesitate to configure it as
restrictively as your special application allows. For instance, if you
want to allow diskless hosts to boot from your machine, you must provide
the TFTP (trivial file transfer service) so that they can download basic
configuration files from the \file{/boot} directory. However, when used
unrestricted, TFTP allows any user anywhere in the world to download any
publicly accessible file from your system. If this is not what you want,
why not restrict TFTP service to the \file{/boot} directory?\footnote{
 We will come back to this in chapter~\ref{appl}.
}


Along the same line of thought, you might want to restrict certain
services to users from certain hosts, say from your local network. 
In chapter~\ref{appl}, we introduce \prog{tcpd} which does this for
a variety of network applications.


Another important point is to avoid ``dangerous'' software. Of course,
any software you use may be dangerous, because software may have bugs
that clever people might exploit to gain access to your system. Things
like these happen, and there's no complete protection against this.
This problem affects free software and commercial products
alike.\footnote{
 There have been commercial \unices{} you have to pay lots of money for
 that came with a setuid-\user{root} shell script which allowed users to
 gain \user{root} privilege using a simple standard trick.
} However, programs that require special privilege are inherently more
dangerous than others, because any loophole can have drastic
consequences.\footnote{
 In 1988, the RTM worm brought much of the Internet to a grinding halt,
 partly by exploiting a gaping hole in some \prog{sendmail} programs.
 Of course, this hole has long been fixed since.
} If you install a setuid program for network purposes be doubly careful
that you don't miss anything from the documentation, so that you don't
create a security breach by accident.


Under worst circumstances, all precautions might fail. You should
therefore make sure you detect intruders early. Checking the system
log files is a good starting point, but the intruder is probably as
clever, and will delete any obvious traces he or she left. However,
there are tools like \prog{tripwire}\footnote{
 Written by Gene Kim and Gene Spafford.
} that allow you to check vital system files to see if their contents or
permissions have been changed.  \prog{tripwire} computes various strong
checksums over these files and stores them in a database.  At a later
run, new checksums are computed and compared to the stored ones to
detect any modifications.


